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Sir: 

This is an appeal from the Final Rejection of the Examiner dated 10/22/2003 finally 
rejecting claims 1,3-5,7-12,23-25, 31, and 32 of the above application. A notice of Appeal 
was timely filed. 

1. REAL PARTY IN INTEREST 

Same as the inventors in the caption of this application: Mikhail Lotvin and Richard 
M. Nemes 

2. RELATED APPEALS AND INTERFERENCES 
None 

3. STATUS OF CLAIMS 

Claims 1, 3-5, 7, 9, 11, 12, 23-25, 31, and 32 are finally rejected under 35 USC 
102(a) as anticipated by the Feldman publication entitled "Intelligent Agents: A Primer"; 
and claims 8 and 10 were rejected as obvious under 35 USC 103(a) in view of the S % 
combination of Feldman and the Pournelle publication entitled "Future Calling". All the # 
claims are recited in full in the accompanying appendix. - 

The remaining claims have been canceled without prejudice as a result of a 
restriction requirement and in the previous amendment. 
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There are no outstanding un-entered amendments in this case. 
5. SUMMARY OF THE INVENTION 

In the preferred system, the user is provided with a separate Internet-accessible 
entity referred to here as the "personal page." On the personal page, a user indicates, for 
example, what he/she wishes to purchase, possibly along with other criteria associated with 
the purchase, such as, for example, a time that the purchase should take place. See Page 2 

A user's purchasing or buying requirements ("B.R.") are stored on his/her personal 
page. Thus, B.R. represent user's acquisition specifications. The meaning of B.R. 
(purchasing/buying requirements; acquisition specifications) is not limited to purchasing or 
buying, and may relate to other requirements stored in connection with a personal page, for 
example, requests for service, information, advertisement, as well as other data. See Page 3 

Vendors have the ability to specify similar criteria, which describe the goods and/or 
services they offer. Vendors can indicate, for example, the prices of their goods, times and 
places that their services are available, etc. Vendors, preferably, do not have personal pages 
on which the specification is done. Preferably, these specifications, called "vendor scripts," 
are embodied in active software/data entities (agents) that traverse sites on the Internet 
visiting sites hosting users' personal pages. Thus, preferably, vendor offerings are embodied 
in software/data agents that are the mobile, active elements in the system and personal 
pages are stationary and more passive in comparison. r \ B.R.'s (vendor scripts) are 
preferably translated to lower level language equivalents and then stored on personal pages, 
referred to as purchase forms. Similar vendor forms are used to represent vendor's offering 
specifications. See Pages 2-3* 

Purchase (and vendor) forms comprise attributes, which are fields such as "attribute" 
notion in the Relational Data- Base Model. Attributes are assigned values, or NULL. For 
example, examples of attributes in a purchase form include: "Action," (having values, for 
example, "purchase", "sell," "trade," "license," "reserve," "rent," "lease," etc.), Item Name, 
Item code, UPC code, Date (of delivery), Place, Supplier, Quantity, Quality, Size, and 
Price. See Page 7 

A purchase form is "satisfied" against a vendor form if all its attribute values are 

compatible with associated attribute values in the vendor form. In the preferred 

embodiment, the determination of compatibility of attributes is aided by a compatibility 

dictionary maintained by the system. The compatibility dictionary is preferably a database 

and associated program logic that indicates whether two or more values in certain attributes 

are deemed compatible. For example, if the value for the Action attribute in a purchase 
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form is "purchase" and the value for the Action attribute in a vendor form is "sell," then the 
dictionary would indicate that these actions are compatible. Action values "buy" and "sell" 
would similarly be deemed compatible values for Action in the dictionary. But "trade" and 
"license" would not be deemed compatible Actions, nor would "buy" and "buy." Similarly, 
the values "100" and " < 1000" would be deemed compatible in all attributes, since 100 is 
less than 1000 universally, and "anytime next week" and "next Wednesday" would also be 
deemed compatible universally. But "100" and " < 50" would be deemed incompatible as 
would "anytime next week" and "in 6 weeks." Geographical attribute values "outside New 
York Metropolitan area" and "Boston" would be deemed compatible, while "New York 
Metropolitan area" and "Taiwan" would be considered incompatible. Preferably, the value 
NULL is compatible with all values, except the special value NOT NULL. See Page 8. 

The scripting language for specifying BR's (acquisition specifications) and vender 
scripts can be an IF-THEN-ELSE control structure as exemplified by the extended BNF 
(Backus-Naur Form) grammar provided on page 11 of the specification. The B.R. 
represented in a scripting language is parsed using known parsing techniques in the field of 
compiler construction and based on an appropriately defined grammar. As a result of the 
parse the original scripting language is converted to separate purchase forms. A vendor 
script is handled analogously, resulting in a similar collection of vendor forms. The 
purchase forms (vendor forms) are ordered according to their occurrence in the B.R. script, 
from top to bottom. Preferably during the parse, each purchase form (vendor form) has 
associated with it a boolean condition that is the conjunction of all the IF conditions 
encountered on the path from the beginning of the B.R. (vendor script) to that purchase 
form. See Page 13. . : 

Fig.7 illustrates software executing on a computer that determines compatibility! 
between acquisition specifications and offering specifications. Preferably, the software 
considers all purchase form sets against newly arrived vendor forms. The vendor forms are 
checked against each purchase form set for compatibility. A vendor and a user whose forms 
have been matched are notified as shown on Fig. 7. Fig. 8 shows how vendor and purchase 
forms are tested for satisfiability. First, the associated booleans are evaluated. If they both 
evaluate to true, then attributes on the forms are checked against each other for 
compatibility using a compatibility dictionary. (See Fig. 9.) If all attribute values are 
compatible, then the forms are deemed compatible, otherwise incompatible. Pages 13-14 

Acquisition specifications can also be entered using voice input whereby the user is 

prompted for information that he/she speaks into a microphone connected to the local 
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computer or into a telephone. User-dependent voice recognition software may be associated 
with a personal page for entering such a voice input. See Page 6 and Fig. 3; Page 22 

After a match was found between acquisition specifications and vendor offerings 
additional verification by all parties regarding the terms of certain deals may be necessary. 
See page 19. In this case, where the system processes the closing of a deal between a buyer 
and seller who require verification of agreement, the following processing is employed. 
First, one of the parties to the deal, the seller, for example, requests a deal identifier (ID) 
from a server supervising the closing of the deal. The deal ID is a unique identification of 
the particular deal, allowing distinguishing from other deals. The user then sends the deal 
ID to the other party. Once both parties have received the same deal ID, one or both parties 
request that the server transmit forms to both parties for a particular type of deal. Types of 
deals may include, for example, sales, swaps, licenses, etc. The form may include a 
description of the property or properties involved in the transaction, identification of the 
parties involved, selling price if applicable, license fees if applicable, date of effect, other 
terms and conditions, etc. In response, the server transmits the deal forms to both parties of 
the deal. Thereafter, both parties independently fill out the terms of the deal using the form 
received from the server. Thereafter, the filled out forms are provided to the sever. The 
server compares the fields in the records identified by the same deal ID's. If the fields in the 
records are compatible, the server marks the deal as closed. Once the deal is closed, the 
server sends confirmation messages, by email, for example, to both the buyer and the seller. 
Seepages 19-29. Fig: 11. i 

The user may also control advertisement using the personal page technique. A user 
could actively invite selective advertisements, which would then be provided to the user by 
vendors* electronic representatives. See Page 23 and Fig. 12 The personal page fsoftware 
may also have access to the geographical location of its owner via GPS, and- the personal- 
page software logic executes in accordance with that current geographical location. See 
Pages 26 and 27 and Figs. 13, 14A, and 14B. 

Nothing herein should be construed as limiting the scope of the claims. 

6. ISSUES 

Whether claims 1,3-5,7, 9, 1 1, 12,23-25, 31, and 32, not anticipated by the Feldman 
publication under 35 USC 102(a); and claims 8 and 10 are not obvious under 35 USC 
103(a) in view of the combination of Feldman and Pournelle publications. 
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7. GROUPING OF CLAIMS 

The claims do not stand or fall together. As will be apparent from the Argument the 
claims are separately patentable. To the extent the final office is understood, different 
claims have been rejected based on different portions of the cited reverences and, thus, the 
claims have been rejected on different grounds. 

Although the claims are separately patentable and rejected on separate grounds, the 
following grouping of the claims will be used to simplify the argument. 

Group 1 : Claims 1 , 3, 23, 24, 25 

Group 2: Claims 4, 5, 10 

Group 3: Claims 7 

Group 4: Claims 8 

Group 5: Claims 9 

Group 6: Claims 11, 31 

Group 7: Claims 12, 32 

8. ARGUMENT 

I. THE 35 U.S.C. §102 (a) REJECTIONS ARE IMPROPER 

35 U.S.C. §102 (a) states that "A person shall be entitled to a patent unless- (a) the 

invention was known or used by others in this country, or patented or described in a printed 

publication in this or a foreign country, before the invention thereof by the applicant for a 

patent". A patent claim is "anticipated" (and hence invalid) if a single prior-art reference f 

contains each and every limitation of the claim, either expressly or inherently. See , e.g. , 

. Karsten Manufacturing Corp. v. Cleveland Golf Co. , 242 F.3d 1376, .1383 (Fed. Cir. 2001) ; 

("Invalidity on the ground of 'anticipation 1 requires lack of novelty of the invention as 

claimed. The invention must have been known to the art in the detail of the claim - that is, - 

all of the elements and limitations of the claim must be shown in a single prior reference, 

arranged as in the claim."). MPEP 2131 also provides the following citations: "A claim is 

anticipated only if each and every element as set forth in the claim is found, either expressly 

or inherently described, in a single prior art reference." Verdegaal Bros. v. Union Oil Co. of 

California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). "The identical 

invention must be shown in as complete detail as is contained in the ... claim." Richardson 

v. Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

As will be explained below the cited art does not anticipate, the rejected claims, as 

asserted by the Examiner. It should be noted, however, that the arguments herein and 
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anywhere else in this prosecution record should not be construed as an admission that the 
cited references constitute prior art to the present invention (the references are dated less 
than one year from the filing date). 

Argument re Group 1: Claims 1, 3, 23, 24, 25 

The argument in connection with claim 1 is presented below. Claim 23 has similar 
apparatus limitations and is patentable for the same reasons. The remaining claims in this 
group are dependent claims of 1 and 23 , and, thus, patentable because the independent 
claims are patentable. 

The Examiner asserts that Feldman on page 2 discloses "intelligent agents," which 
are software programs inherently comprising scripts. Apparently this page has been cited 
for the first step of claim 1, which states: "storing at least one acquisition specification of a 
first user represented in a scripting language that specifies acquisition requirements." First, 
the Examiner provides no basis for the assertion that a programming language in Feldman 
includes scripts, which are used for acquisition specifications. The Examiner merely states 
that computer programs inherently include scripts. This assertion is neither correct nor any 
support was provided by the Examiner. In fact, to the contrary, there is no teaching or 
suggestion in Feldman that may in any way concern "acquisition specification of a first user 
represented in a scripting language." The Examiner also asserts that on page 15, Feldman 
describes that the agent may be dispatched to find best price according to user's criteria. 
But again, Feldman provides no teaching or suggestion for the "acquisition specification of 
a first user represented in a scripting language." 

The Examiner provides no citation in Feldman regarding the next step of "parsing the 
acquisition specification into at least one purchase form comprising a plurality of attributes, 
at least one of which specifying a transactional action desired to be electronically completed 
by the first user." (See claim 1). There is no teaching or suggestion of this functionality in 
Feldman and the Examiner apparently does not assert otherwise. 

Similarly, the Examiner provides no citation in Feldman regarding the following step 
of "receiving over the Internet and storing offering specification comprising at least one 
vendor form comprising a plurality of attributes, at least one of which specifying a 
transactional action desired to be electronically completed by a second user." (See claim 1). 
There is no teaching or suggestion of this functionality in Feldman and the Examiner 
apparently does not assert otherwise. 
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The examiner cites Page 5 of Feldman (see page 3 of the Final Office Action) 
concerning the agents, that can perform "information flow functions: finding, searching, 
filtering, categorizing, storing, routing, and/or selectively disseminating information", 
apparently for the last step of claim 1: "electronically determining if the attributes in the 
purchase form are compatible with associated attributes in the vendor form by testing 
attributes in the purchase form against attributes in the vendor form for satisfiability using a 
compatibility dictionary, comprising a storage of sets of compatible terms associated with 
an automated completion of a transaction, wherein the step of testing comprises accessing 
the storage of the dictionary and determining whether the transactional action in the 
purchase form is compatible with the transactional action in the vendor form." But, the 
functions listed by the Examiner is not recited in this step. Further, nothing else in Feldman 
can be used as a teaching for this step (or element, claim 23). Although the Examiner 
asserts that in Feldman agent can find bids that match user's requirements, this does not in 
any way teach or suggest the specific claimed techniques as quoted above, including the use 
of the compatibility dictionary for "determining whether the transactional action in the 
purchase form is compatible with the transactional action in the vendor form". 

The Examiner asserts that the compatibility dictionary is suggested by Feldman ! s 
statement* "[cjomputers need rules and instructions" and because such rules include the 
ability to "identify patterns, note similarities, differences and change" (See page 2 of the 
Final Office Action). The €xaminer in fact admits that the compatibility dictionary is not 
disclosed by Feldman, but asserts that "[i]t would be obvious that a computer would be 
taught the importance of matching compatible terms ..." (Page 2 of the Final Office 
Action). First, obviousness cannot be used as a basis for the anticipation (102) rejection. 
Thus, the Examiner plainly admitted that the rejection is improper. But even under the 
obviousness standard, the Examiner's analysis is incorrect, since the Examiner uses 
hindsight to claim obviousness based on pure speculation. 

It should be noted, that the compatibility dictionary is unique and differs from other 

look-up techniques in that it stores pairs of terms that are semantically compatible in a 

transaction sense. Traditional "dictionaries," store collections of synonyms and/or 

antonyms. Essentially they are thesauruses. The compatibility dictionary, on the other hand, 

contains pairs of transactionally compatible terms such as "buy/sell," "lend/borrow," 

"trade/trade," and "luxurious hotel/five-star-hotel." The concept of a compatibility 

dictionary is clearly not disclosed or suggested by Feldman. 
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Thus, none of the steps / elements of claims 1 and 23 are taught (or even suggested) 
by Feldman. Accordingly claims 1 and 23 and their dependent claims are not anticipated 
and patentable for a number of reasons. 

Argument re Group2 : Claims 4, 5 

Claim 4 states as follows: "The method of claim 1 wherein the storing the at least 
one acquisition specification is on a personal page assigned to a user providing the 
acquisition specification.' 1 

Examiner does not specifically state the reasons for rejecting this claim, except for 
citing the Feldman reference in general. No specific place in Feldman is indicated as 
anticipating this claim. The concept of a "personal page" is clearly not fund by the cited art. 
The personal page is provided to a user '. -r ' jy-x for storing criteria associated with user's 
purchases. Unlike conventional systems that sell products electronically, in the preferred 
system buyer information is preferably stationary and stored on the personal page, while 
seller information is provided preferably by a mobile entity. Thus, the preferred system can 
be viewed as an inversion of the known model. 

There is nothing in Feldman even remotely suggesting the personal page as defined 
in the specification and, therefore, claims 4 and 5 are not anticipated and patentable for this 
additional reason. (Please note that 5 is dependent on 4). 

Argument re Group 3: Claim 7 



Claim 7 states as follows: "The^method of claim .1 wherein the acquisition specification 
comprises data related to at least one advertisement." ^ 

The Examiner asserts that the fact that the agent disclosed in Feldman acts on behalf 
of a user and interacts with external environment inherently includes a teaching of the 
advertisement in this context. Examiner provides no support for this assertion. This is 
merely a conclusive statement that has no foundation. In fact, nothing in Feldman address 
the subject matter of this claim. Since the Examiner failed to demonstrate any reason for 
this conclusive assertion of inherent anticipation, the rejection is improper. 

Thus, this dependent claims 7 is not anticipated and patentable for this additional 

reason. 

Argument re Group £ Claim 9 
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Claim 9 states as follows: "The method of claim 4 wherein voice recognition 
software is associated with the personal page and the acquisition specification is provided 
using voice input." Presumably (though not specifically stated), the Examiner cites for this 
claim an interface that answers questions "though a spoken interface." (page 15 of 
Feldman). Although the publication mentions generated speech, it does not teach or 
suggest using voice recognition software. And, of course, there is no teaching or suggestion 
of using voice recognition to provide an acquisition specification to a personal page. 

Thus, this dependent claims 9 is not anticipated and patentable for this additional 

reason. 

Argument re Group 6: Claims 11,31 

Examiner does not specifically state the reasons for rejecting claims 11 and 31, 
except for citing the Feldman reference in general. These claims recite the steps / elements 
of electronic contracting which include the following functionality: 1) providing a deal 
identifier to first user; 2) receiving from the first user a first electronic contract and the deal 
identifier; 3) providing a second user with the deal identifier; 4) receiving from the second 
user a second electronic contract and the deal identifier; and 5) determining if the 
transmitted first and second contracts are compatible. A review of Feldman reveals that 
nothing in the cited publication has any steps / elements of this claim. In fact the 
publication at issue does not addresses the subject matter of electronic contracting and the 
Examiner did not point out any place in the publication that may be relevant. 

Accordingly claims 1 1 and 3 1 are not anticipated and patentable. 

Argument re Group 7: Claims 12^32 - > 

Independent claims 12 and 32 recite steps / elements having the following 
functionality: (1) electronically indexing using at least one index value into a compatibility 
dictionary; and (2) electronically extracting a compatibility designation based on the at least 
one index value. 

First, as discussed in connection with claims 1 an 23 (Group 1) the Examiner 

admitted that the compatibility dictionary is not taught by Feldman. Further, as also 

discussed in connection with Group 1, there is no suggestion of the concept of the 

compatibility dictionary in Feldman and no motivation is provided therein to use such a 

compatibility dictionary. Finally claims 12 and 32 recite specific steps of indexing and 
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extracting, neither of which are disclosed in Feldman and the Examiner does not argue 
otherwise in the office action at issue. 

Accordingly claims 12 and 32 are not anticipated and patentable. 



II. The 35 U.S.C. §103 (a) REJECTIONS ARE IMPROPER 
35 USC 103 (a) states: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having ordinary 
skill in the art to which said subject matter pertains. Patentability shall not be negatived by 
the manner in which the invention was made. 

MPEP2141 explains : 

"When applying 35 U.S.C. 103, the following tenets of patent law must be adhered to: 

(A) The claimed invention must be considered as a whole; 

(B) The references must be considered as a whole and must suggest the desirability and thus 
the obviousness of making the combination; 

(C) The references must be vtewed without the benefit of impermissible hindsight vision v ■•. 
afforded by the claimed invention; and 

(D) Reasonable expectation of success is the standard with which obviousness is 
determined." 1 * ' " , : 

Further MPEP 2142 explains: "To establish a prima facie case of obviousness, three basic 
criteria must be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference (or references when 
combined) must teach or suggest all the claim limitations. The teaching or suggestion to 
make the claimed combination and the reasonable expectation of success must both be 
found in the prior art, and not based on applicant's disclosure." 
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MPEP 2143.01 explains: "The mere fact that references can be combined or modified does 
not render the resultant combination obvious unless the prior art also suggests the 
desirability of the combination." 

Argument re Group 4: Claim 8 

Claim 8 states as follows: "The method of claim 4 wherein the personal page 
communicates with Global Positioning System." 

The cited page 4 of the Pournelle reference merely states that in a few years 
"anybody can have an intelligent software assistant for shopping simply by talking to the 
combination phone-computer camera that all will carry..." Not only the recited GPS is not 
mentioned, there is no suggestion or motivation expressed to combine this reference with 
the Feldman reference. The Examiner admits that the "communicates with Global 
Positioning System" is absent from either cited publication and uses classical prohibited 
hindsight to fill in the gaps in the analysis that cannot be filled. 

Thus, this dependent claims 8 is not obvious and patentable for this additional 

reason. 

CONCLUSION 

As demonstrated above the rejected claims are patentable. 

Appellants respectfully request that the Examiner's rejections^ ' ^i^-i % o a > - 
:. be reversed 

An oral argument is NOT requested. 



Respectfully submitted, 




Date 



Mikhail Lotvin 



Richard M. Nemes 



Address: 



2231 56th Drive 



Brooklyn, New York 1 1234-6840 U.S.A. 
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Phone: (718)531-2947 
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APPENDIX 

1 . A computer-implemented method comprising: 

storing at least one acquisition specification of a first user represented in a scripting 
language that specifies acquisition requirements; 

parsing the acquisition specification into at least one purchase form comprising a 
plurality of attributes, at least one of which specifying a transactional action desired to be 
electronically completed by the first user; 

receiving over the Internet and storing offering specification comprising at least one 
vendor form comprising a plurality of attributes, at least one of which specifying a 
transactional action desired to be electronically completed by a second user; and 

electronically determining if the attributes in the purchase form are compatible with 
associated attributes in the vendor form by testing attributes in the purchase form against 
attributes in the vendor form for satisfiability using a compatibility dictionary, comprising a 
storage of sets of compatible terms associated with an automated completion of a 
transaction, wherein the step of testing comprises accessing the storage of the dictionary 
and determining whether the transactional action in the purchase form is compatible with 
the transactional action in the vendor form. 

3. The method of claim 1 wherein the at least one offering specification comprises data 
represented by a scripting languages. 

4. The method of claim 1 wherein the storing the at least one acquisition specification is on 
a personal page assigned to a user providing the acquisition specification. 

5. The method of claim 4 wherein the offering specification is received at the location 
where the personal page with at least one acquisition specification is stored. 

7. The method of claim 1 wherein the acquisition specification comprises data related to at 
least one advertisement. 

8. The method of claim 4 wherein the personal page communicates with Global Positioning 



System. 
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9. The method of claim 4 wherein voice recognition software is associated with the personal 
page and the acquisition specification is provided using voice input. 

10. The method of claim 4 wherein the acquisition specification is provided to the personal 
page using wireless communication. 

1 1. A computer-implemented method comprising: 

electronically providing to a first user to obtain a deal identifier; 
receiving from the first user a first electronic contract and the deal identifier; 
electronically providing a second user with the deal identifier; 
receiving from the second user a second electronic contract and the deal 
identifier; and 

determining if the transmitted first and second contracts are compatible. 

12. A computer-implemented method comprising: 

electronically indexing using at least one index value into a compatibility 
dictionary; and 

electronically extracting a compatibility designation based on the at least one 
index value. 

23. [Aio. r ;> , A computer system comprising: 

memory storing at least one acquisition specification of a first user comprising data 
represented by a scripting language that specifies acquisition requirements; . 

means for parsing the acquisition specification into at least one purchase form 
comprising a plurality of attributes, at least one of which specifying a transactional action 
desired to be electronically completed by the first user; 

means for receiving over the Internet and storing at least one offering specification 
comprising at least one vendor form comprising a plurality of attributes, at least one of 
which specifying a transactional action desired to be electronically completed by a second 
user; and 

means for electronically determining if the attributes in the purchase form are 
compatible with associated attributes in the vendor form by testing attributes in the 
purchase form against attributes in the vendor form for satisfiability using a compatibility 
dictionary, comprising a storage of sets of compatible terms associated with an automated 
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completion of a transaction, wherein the testing comprises accessing the storage of the 
dictionary and determining whether the transactional action in the purchase form is 
compatible with the transactional action in the vendor form. 

24. The system of claim 23 wherein the means for electronically receiving comprises means 
for communication over the Internet. 

25. The system of claim 24 wherein the at least one offering specification comprises data 
represented by a scripting languages. 

31. A computer system comprising: 

means for electronically providing to a first user to obtain a deal identifier; 
means for receiving from the first user a first electronic contract and the deal 
identifier; 

means for electronically providing a second user with the deal identifier; 

means for receiving from the second user a second electronic contract and 
the deal identifier; and 

means for determining if the transmitted first and second contracts are 
compatible; 

32. A computer system comprising: 

means for electronically indexing using at least one index value into a compatibility 
dictionary; and 

means for electronically extracting a compatibility designation based on the at least 
one index value. . . 
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